1. Technical Field
The present invention relates in general to a system and method for simulating hardware interrupts. More particularly, the present invention relates to a system and method for a compiler to insert external branch statements in code operating in an environment where there are no hardware interrupts.
2. Description of the Related Art
Originally, computer systems were single-task devices that performed one set of instructions until the operation was complete. Processors were developed that provided the ability to interrupt a process by using a processor-enabled hardware interrupt. The operating system, or the individual process, receives the interrupt, determines what is being requested, and handles the interrupt. In general purpose computing environments, interrupts often occur many times per second. Interrupting processes allows the computing system to multitask and appear that multiple processes are running concurrently when, instead, each process is sharing the processor and running in a small time slice before the processor switches to a different process. However, even in modern computer system, some processors do not have interrupt capabilities. The lack of interrupt capabilities make it difficult to task switch in these environments. A program running on a non-interruptable processor typically must poll, or look for, a request that is waiting to be processed. If a program is poorly written and does not poll for such interruptions frequently enough, the request waits for a long period of time.
One environment that provides fewer hardware interrupt capabilities is a heterogeneous processor environment that includes a primary processing unit (PU) and one or more secondary synergistic processing units (SPUs). The PU boots-up and initializes the computer system during which time the PU loads an operating system. The PU has interrupt capabilities and the operating system that runs on the PU is able to switch from one task to another. Conversely, the SPU runs extremely fast in comparison to the PU but has a limited instruction set and does not have hardware interrupt capabilities.
The operating system running on the PU performs basic tasks, such as recognizing input from a keyboard, sending output to a display screen, keeping track of files and directories on a disk, and controlling peripheral devices, such as disk drives and printers. The operating system includes a kernel that is a central module of the operating system and is responsible for memory management, process management, task management, and disk management.
The kernel loads a PU program into the PU's internal memory. During the loading process, the kernel identifies a runtime loader that corresponds to the PU program. The runtime loader is responsible for loading objects, resolving symbols, and loading other files (i.e. data, programs) that correspond to the PU program. The kernel loads the runtime loader into the PU's internal memory and passes control to the runtime loader. The runtime loader identifies files that the PU program depends, such as an SPU file. The runtime loader loads the SPU file into the PU's internal memory, and extracts a processor identifier from the SPU file's header. For example, the SPU file may be an ELF formatted file in which case the file includes a “machine type SPU” in its ELF header which is a processor identifier that correlates the file to an SPU.
The runtime loader determines that the SPU file should run on an SPU based upon the SPU file's processor identifier, and sends the SPU file to an SPU using a DMA command. The SPU receives the SPU file and stores it in the SPU's local memory. The SPU begins executing the SPU file, and, in turn, loads an SPU runtime loader in its internal memory. However, because the SPU does not have hardware interrupts, the program running in the SPU is not able to receive and process an interrupt, the program must either poll for waiting requests or, if the program does not look for waiting requests, the program runs on the SPU until it completes.
During the SPU file's execution, the SPU runtime loader retrieves and loads files in which the SPU file depends. For example, the SPU file may be a graphics program whereby it requires a plug-in module for manipulating data. The SPU runtime loader recognizes that the SPU file requires a plug-in, and sends a request to the PU. The PU receives the request, and retrieves the plug-in from system memory. The PU program sends the plug-in to the SPU runtime loader using a DMA command whereby the SPU runtime loader stores the plug-in in SPU internal memory. The SPU file may also receive data from the PU program using the same technique as described above. Again, because the SPU does not support hardware interrupts, the data waiting to be processed by the SPU program waits for the SPU program to poll memory and determine that the data is waiting.
One approach to handling the challenge of signaling a processor in this environment would be to add hardware interrupt capabilities to the processors. This, however, adds additional unwanted complexity to the SPUs. Another approach is for programs to poll for requests, as described above. The trouble with this approach is that if programs poll too frequently for requests, too much processing time is wasted performing the polls, however, if the programs do not poll frequently enough, the request waits too long to be processed.
What is needed, therefore, is a system and method for simulating an interrupts in the SPU. Furthermore, what is needed is a system and method that automatically adds the simulated interrupts when compiling a program without relying on individual programmers to code the interrupt simulation. Finally, what is needed is a system and method that simulates hardware interrupts without adding undue processing requirements to programs running on the SPU.